JVM实战(2)

一、几个概念： 1、jstack命令的语法格式：jstack ，可用于查看java进程id。 2、Dump文件：Dump文件是进程的内存镜像。可以把程序的执行状态通过调试器保存到dump文件中。Dump文件是用来给驱动程序编写人员调试驱动程序用的，这种文件必须用专门的工具软件打开，比如使用Windbg。 在Windbg中可以通过.dump命令保存进程的dump文件。比如下面的命令把当前进程的镜像保存为c:\testdump.dmp文件：.dump /ma c:\testdump.dmp。 其中、ma参数表示dump文件应该包含进程的完整信息，包括整个用户态的内存，这样dump文件尺寸会比较大，信息非常全面。如果不是用、ma参数，保存下来的dump文件只包含了部分重要资料，比如寄存器和线程栈空间，文件尺寸会比较小，无法分析所有的数据。 3、java线程Dump：线程dump是非常有用的诊断java应用问题的工具，每一个java虚拟机都有及时生成显示所有线程在某一点状态的线程dump的能力。虽然各个java虚拟机线程dump打印输出格式上略微有一些不同，但是线程dump出来的信息包含线程基本信息；线程的运行状态、标识和调用的堆栈；调用的堆栈包含完整的类名，所执行的方法，如果可能的话还有源代码的行数。 JVM中的许多问题都可以使用线程dump文件来进行诊断，其中比较典型的包括线程阻塞，CPU使用率过高，JVM Crash，堆内存不足和类装载等问题。 一般情况下，通过jstack输出的线程信息主要包括：jvm自身线程、用户线程等。其中jvm线程会在jvm启动时就会存在。对于用户线程则是在用户访问时才会生成。

或者可以使用一下命令将线程信息存入文件中：#jstack -l pid > jstack.log 其中标注daemon字样的是后台线程。以上的用户线程中包括：

1、线程的一些基本信息：名称、优先级及id 2、线程状态：waiting on condition等 3、线程的调用栈 4、线程锁住的资源：locked

二、Monitor（监视器）   在多线程的java程序中，实现线程之间的同步，就要说说Monitor。Monitor是java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者Class的锁。每一个对象都有，也仅有一个Monitor。下面这个图描述了线程和Monitor之间的关系，以及线程的状态转换图：

1、进入区（Entry Set）：表示线程通过synchronized要求获取对象的锁。如果对象未被锁住，则进入拥有者；否则在进入区等待。一旦对象锁被其他线程释放，立即参与竞争。 2、拥有者（The Owner）：表示某一线程成功竞争到对象锁。 3、等待区（Wait Set）：表示线程通过对象的wait方法释放对象的锁，并在等待区等待被唤醒。

  从图中可以看出，一个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在“Wait Set”中等待的线程状态是 “in Object.wait()”。 先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像：

三、调用修饰：   表示线程在方法调用时额外的重要操作。线程dump分析的重要信息。修饰上方的方法调用。

1、locked目标：使用synchronized申请对象锁成功，监视器的拥有者； 2、waiting to lock目标：使用synchronized申请对象锁未成功，在进入区等待； 3、waiting on目标：使用synchronized申请对象锁成功后，调用了wait方法，进入对象的等待区等待。在调用栈顶出线，线程状态为WAITING或TIMED_WAITING； 4、parking to wait for目标：park是基本的线程阻塞原语，不通过监视器在对象上阻塞。随concurrent包出现的新的机制，与synchronized体系不同；

四、线程状态   想要通过jstack命令来分析线程的情况的话，首先要知道线程都有哪些状态，下面这些状态是我们使用jstack命令查看线程堆栈信息时可能会看到的线程的几种状态：

1、NEW,未启动的。不会出现在Dump中。 2、RUNNABLE,在虚拟机内执行的。 3、BLOCKED,受阻塞并等待监视器锁。 4、WATING,无限期等待另一个线程执行特定操作。 5、TIMED_WATING,有时限的等待另一个线程的特定操作。 6、TERMINATED,已退出的。

五、线程动作： 线程状态产生的原因：

1、runnable：状态一般为RUNNABLE，表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。 2、in Object.wait()：等待区等待，状态为WAITING或TIMED_WAITING。 3、waiting for monitor entry：进入区等待，状态为BLOCKED。 4、waiting on condition：等待去等待，被park。 5、sleeping：休眠的线程，调用了Thread.sleep()。

  Wait on condition 该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。 最常见的情况就是线程处于sleep状态，等待被唤醒。 常见的情况还有等待网络IO：在java引入nio之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。   在 NIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读 写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。六、线程分析 1. JVM 线程   在线程中，有一些 JVM内部的后台线程，来执行譬如垃圾回收，或者低内存的检测等等任务，这些线程往往在 JVM初始化的时候就存在，如下所示：

我们更多的是要观察用户级别的线程，如下所示：

我们能看到： * 线程的状态： waiting on condition * 线程的调用栈 * 线程的当前锁住的资源：

2. 线程的状态分析   正如我们刚看到的那样，线程的状态是一个重要的指标，它会显示在线程 Stacktrace的头一行结尾的地方。那么线程常见的有哪些状态呢？线程在什么样的情况下会进入这种状态呢？我们能从中发现什么线索？ 2.1 Runnable   该状态表示线程具备所有运行条件，在运行队列中准备操作系统的调度，或者正在运行。 2.2 Wait on condition   该状态出现在线程等待某个条件的发生。具体是什么原因，可以结合 stacktrace来分析。最常见的情况是线程在等待网络的读写，比如当网络数据没有准备好读时，线程处于这种等待状态，而一旦有数据准备好读之后，线程会重新激活，读取并处理数据。在 Java引入 NewIO之前，对于每个网络连接，都有一个对应的线程来处理网络的读写操作，即使没有可读写的数据，线程仍然阻塞在读写操作上，这样有可能造成资源浪费，而且给操作系统的线程调度也带来压力。在 NewIO里采用了新的机制，编写的服务器程序的性能和可扩展性都得到提高。   如果发现有大量的线程都在处在 Wait on condition，从线程 stack看， 正等待网络读写，这可能是一个网络瓶颈的征兆。因为网络阻塞导致线程无法执行。一种情况是网络非常忙，几 乎消耗了所有的带宽，仍然有大量数据等待网络读 写；另一种情况也可能是网络空闲，但由于路由等问题，导致包无法正常的到达。所以要结合系统的一些性能观察工具来综合分析，比如 netstat统计单位时间的发送包的数目，如果很明显超过了所在网络带宽的限制 ; 观察 cpu的利用率，如果系统态的 CPU时间，相对于用户态的 CPU时间比例较高；如果程序运行在 Solaris 10平台上，可以用 dtrace工具看系统调用的情况，如果观察到 read/write的系统调用的次数或者运行时间遥遥领先；这些都指向由于网络带宽所限导致的网络瓶颈。另外一种出现 Wait on condition的常见情况是该线程在 sleep，等待 sleep的时间到了时候，将被唤醒。 2.3 Waiting for monitor entry 和 in Object.wait()   在多线程的 JAVA程序中，实现线程之间的同步，就要说说 Monitor。 Monitor是 Java中用以实现线程之间的互斥与协作的主要手段，它可以看成是对象或者 Class的锁。每一个对象都有，也仅有一个 monitor。每个 Monitor在某个时刻，只能被一个线程拥有，该线程就是 “Active Thread”，而其它线程都是 “Waiting Thread”，分别在两个队列 “ Entry Set”和 “Wait Set”里面等候。在 “Entry Set”中等待的线程状态是 “Waiting for monitor entry”，而在 “Wait Set”中等待的线程状态是 “in Object.wait()”。 先看 “Entry Set”里面的线程。我们称被 synchronized保护起来的代码段为临界区。当一个线程申请进入临界区时，它就进入了 “Entry Set”队列。对应的 code就像：

这时有两种可能性： 1、该 monitor不被其它线程拥有， Entry Set里面也没有其它等待线程。本线程即成为相应类或者对象的 Monitor的 Owner，执行临界区的代码 2、该 monitor被其它线程拥有，本线程在 Entry Set队列中等待。   在第一种情况下，线程将处于 “Runnable”的状态，而第二种情况下，线程 DUMP会显示处于 “waiting for monitor entry”。如下所示：

  临界区的设置，是为了保证其内部的代码执行的原子性和完整性。但是因为临界区在任何时间只允许线程串行通过，这 和我们多线程的程序的初衷是相反的。 如果在多线程的程序中，大量使用 synchronized，或者不适当的使用了它，会造成大量线程在临界区的入口等待，造成系统的性能大幅下降。如果在线程 DUMP中发现了这个情况，应该审查源码，改进程序。   现在我们再来看现在线程为什么会进入 “Wait Set”。当线程获得了 Monitor，进入了临界区之后，如果发现线程继续运行的条件没有满足，它则调用对象（一般就是被 synchronized 的对象）的 wait() 方法，放弃了 Monitor，进入 “Wait Set”队列。只有当别的线程在该对象上调用了 notify() 或者 notifyAll() ， “ Wait Set”队列中线程才得到机会去竞争，但是只有一个线程获得对象的 Monitor，恢复到运行态。在 “Wait Set”中的线程， DUMP中表现为： in Object.wait()，类似于：

仔细观察上面的 DUMP信息，你会发现它有以下两行： - locked (a java.util.ArrayList) - waiting on (a java.util.ArrayList)   这里需要解释一下，为什么先 lock了这个对象，然后又 waiting on同一个对象呢？让我们看看这个线程对应的代码：

  线程的执行中，先用 synchronized 获得了这个对象的 Monitor（对应于 locked ）。当执行到 obj.wait(), 线程即放弃了 Monitor的所有权，进入 “wait set”队列（对应于 waiting on ）。   往往在你的程序中，会出现多个类似的线程，他们都有相似的 DUMP信息。这也可能是正常的。比如，在程序中，有多个服务线程，设计成从一个队列里面读取请求数据。这个队列就是 lock以及 waiting on的对象。当队列为空的时候，这些线程都会在这个队列上等待，直到队列有了数据，这些线程被 Notify，当然只有一个线程获得了 lock，继续执行，而其它线程继续等待。

七. JDK 5.0 的 lock   上面我们提到如果 synchronized和 monitor机制运用不当，可能会造成多线程程序的性能问题。在 JDK 5.0中，引入了 Lock机制，从而使开发者能更灵活的开发高性能的并发多线程程序，可以替代以往 JDK中的 synchronized和 Monitor的 机制。但是，要注意的是，因为 Lock类只是一个普通类， JVM无从得知 Lock对象的占用情况，所以在线程 DUMP中，也不会包含关于 Lock的信息， 关于死锁等问题，就不如用 synchronized的编程方式容易识别。

八、使用实例 1、jstack pid

“Attach Listener” daemon prio=10 tid=0x70e95400 nid=0x2265 waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE

“http-bio-8080-exec-20” daemon prio=10 tid=0x08a35800 nid=0x1d42 waiting on condition [0x70997000] java.lang.Thread.State: WAITING (parking) at sun.misc.Unsafe.park(Native Method)

#jstack -l 4089 >1.txt，查看1.txt内容如下所示：

“Attach Listener” daemon prio=10 tid=0x08251400 nid=0x11bd runnable [0x00000000] java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

“DestroyJavaVM” prio=10 tid=0xb3a0a800 nid=0xffa waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

“Query Listener” prio=10 tid=0xb3a09800 nid=0x1023 runnable [0xb3b72000] java.lang.Thread.State: RUNNABLE at java.net.PlainSocketImpl.socketAccept(Native Method) at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)

“Low Memory Detector” daemon prio=10 tid=0x08220400 nid=0x1000 runnable [0x00000000] java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

“C1 CompilerThread0” daemon prio=10 tid=0x08214c00 nid=0xfff waiting on condition [0x00000000] java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

“Signal Dispatcher” daemon prio=10 tid=0x08213000 nid=0xffe runnable [0x00000000] java.lang.Thread.State: RUNNABLE

Locked ownable synchronizers:

“Finalizer” daemon prio=10 tid=0x0820bc00 nid=0xffd in Object.wait() [0xb5075000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method)

Locked ownable synchronizers:

“Reference Handler” daemon prio=10 tid=0x0820a400 nid=0xffc in Object.wait() [0xb50c7000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method)

Locked ownable synchronizers:

“VM Thread” prio=10 tid=0x08200000 nid=0xffb runnable

“VM Periodic Task Thread” prio=10 tid=0x08222400 nid=0x1001 waiting on condition

JNI global references: 1317

  一般情况下，通过jstack输出的线程信息主要包括：jvm自身线程、用户线程等。其中jvm线程会在jvm启动时就会存在。对于用户线程则是在用户访问时才会生成。 2、jstack 查看线程具体在做什么，可看出哪些线程在长时间占用CPU，尽快定位问题和解决问题:JVM性能调优——使用jstack找出最耗CPU的java线程

九、遇到线程问题时如何分析 1、线程Dump的分析原则   结合代码阅读的推理。需要线程Dump和源码的相互推导和印证。造成Bug的根源往往丌会在调用栈上直接体现,一定格外注意线程当前调用之前的所有调用。入手点 进入区等待

线程状态BLOCKED,线程动作wait on monitor entry,调用修饰waiting to lock总是一起出现。表示在代码级别已经存在冲突的调用。必然有问题的代码,需要尽可能减少其发生。 同步块阻塞 一个线程锁住某对象,大量其他线程在该对象上等待。

持续运行的IO IO操作是可以以RUNNABLE状态达成阻塞。例如:数据库死锁、网络读写。 格外注意对IO线程的真实状态的分析。 一般来说,被捕捉到RUNNABLE的IO调用,都是有问题的。   以下堆栈显示： 线程状态为RUNNABLE。 调用栈在SocketInputStream或SocketImpl上,socketRead0等方法。 调用栈包含了jdbc相关的包。很可能发生了数据库死锁

分线程调度的休眠 正常的线程池等待

可疑的线程等待

入手点总结

wait on monitor entry： 被阻塞的,肯定有问题 runnable ： 注意IO线程 in Object.wait()： 注意非线程池等待

2、死锁分析   学会了怎么使用jstack命令之后，我们就可以看看，如何使用jstack分析死锁了，这也是我们一定要掌握的内容。 啥叫死锁？ 所谓死锁： 是指两个或两个以上的进程在执行过程中，由于竞争资源或者由于彼此通信而造成的一种阻塞的现象，若无外力作用，它们都将无法推进下去。此时称系统处于死锁状态或系统产生了死锁，这些永远在互相等待的进程称为死锁进程。 说白了，我现在想吃鸡蛋灌饼，桌子上放着鸡蛋和饼，但是我和我的朋友同时分别拿起了鸡蛋和病，我手里拿着鸡蛋，但是我需要他手里的饼。他手里拿着饼，但是他想要我手里的鸡蛋。就这样，如果不能同时拿到鸡蛋和饼，那我们就不能继续做后面的工作（做鸡蛋灌饼）。所以，这就造成了死锁。 看一段死锁的程序：

class Suo { static Object o1 = new Object(); static Object o2 = new Object(); }

“Thread-1”: waiting to lock monitor 0x00007f0134003ae8 (object 0x00000007d6aa2c98, a java.lang.Object), which is held by "Thread-0"“Thread-0”: waiting to lock monitor 0x00007f0134006168 (object 0x00000007d6aa2ca8, a java.lang.Object), which is held by “Thread-1”

“Thread-1”: at javaCommand.DeadLockclass.run(JStackDemo.java:40)

  Found 1 deadlock.堆栈写的很明显，它告诉我们 Found one Java-level deadlock，然后指出造成死锁的两个线程的内容。然后，又通过 Java stack information for the threads listed above来显示更详细的死锁的信息。 他说 Thread-1在想要执行第40行的时候，当前锁住了资源,但是他在等待资源Thread-0在想要执行第27行的时候，当前锁住了资源,但是他在等待资源 由于这两个线程都持有资源，并且都需要对方的资源，所以造成了死锁。 原因我们找到了，就可以具体问题具体分析，解决这个死锁了。 3、热锁分析   热锁，也往往是导致系统性能瓶颈的主要因素。其表现特征为，由于多个线程对临界区，或者锁的竞争，可能出现： * 频繁的线程的上下文切换：从操作系统对线程的调度来看，当 线程在等待资源而阻塞的时候，操作系统会将之切换出来，放到等待的队列，当线程获得资源之后，调度算法会将这个线程切换进去，放到执行队列中。 * 大量的系统调用：因为线程的上下文切换，以及热锁的竞争，或 者临界区的频繁的进出，都可能导致大量的系统调用。 * 大部分 CPU开销用在 “系统态 ”：线程上下文切换，和系统调用，都会导致 CPU在 “系统态 ”运行，换而言之，虽然系统很忙碌，但是 CPU用在 “用户态 ”的比例较小，应用程序得不到充分的 CPU资源。 * 随着 CPU数目的增多，系统的性能反而下降。因为 CPU数目多，同 时运行的线程就越多，可能就会造成更频繁的线程上下文切换和系统态的 CPU开销，从而导致更糟糕的性能。   上面的描述，都是一个 scalability（可扩展性）很差的系统的表现。从整体的性能指标看，由于线程热锁的存在，程序的响应时间会变长，吞吐量会降低。   那么，怎么去了解 “热锁 ”出现在什么地方呢？一个重要的方法还是结合操作系统的各种工具观察系统资源使用状况，以及收集 Java线程的 DUMP信息，看线程都阻塞在什么方法上，了解原因，才能找到对应的解决方法。    我们曾经遇到过这样的例子，程序运行时，出现了以上指出的各种现象，通过观察操作系统的资源使用统计信息，以及线程 DUMP信息，确定了程序中热锁的存在，并发现大多数的线程状态都是 Waiting for monitor entry或者 Wait on monitor，且是阻塞在压缩和解压缩的方法上。后来采用第三方的压缩包 javalib替代 JDK自带的压缩包后，系统的性能提高了几倍。其他   虚拟机执行Full GC时,会阻塞所有的用户线程。因此,即时获取到同步锁的线程也有可能被阻塞。 在查看线程Dump时,首先查看内存使用情况。 jstack -m 会打印出JVM堆栈信息，涉及C、C++部分代码，可能需要配合gdb命令来分析。频繁GC问题或内存溢出问题 一、使用jps查看线程ID 二、使用jstat -gc 3331 250 20 查看gc情况，一般比较关注PERM区的情况，查看GC的增长情况。 三、使用jstat -gccause：额外输出上次GC原因 四、使用jmap -dump:format=b,file=heapDump 3331生成堆转储文件 五、使用jhat或者可视化工具（Eclipse Memory Analyzer 、IBM HeapAnalyzer）分析堆情况。 六、结合代码解决内存溢出或泄露问题。死锁问题 一、使用jps查看线程ID 二、使用jstack 3331：查看线程情况